AI 에이전트에 샌드박스와 승인 게이트가 필요한 이유
AI 에이전트에 샌드박스와 승인 게이트가 필요한 이유
코드를 직접 수정하고 명령을 실행하는 AI 에이전트는 프롬프트만으로 안전해지지 않는다. 제안과 실행의 분리, 영속적인 승인 상태, 격리된 쓰기 공간, 검토 가능한 결과가 필요하다.
본문의 코드는 특정 저장소 구현을 복사하지 않고 개념을 설명하기 위해 재구성한 예시다. 이름·경로·수치는 실제 운영 정보와 무관하다.
AI 에이전트에게 코드를 읽는 권한만 주면 할 수 있는 일은 제한적이다. 실제로 버그를 고치려면 파일을 바꾸고, 명령을 실행하고, 테스트를 돌리고, 때로는 Git 브랜치나 PR을 만들어야 한다.
하지만 능력을 추가할수록 실수의 반경도 커진다. 잘못된 명령이 작업 디렉터리 밖을 변경하거나, 시크릿이 외부 서비스에 불필요한 요청을 보내거나, 재시도 때문에 같은 작업이 두 번 실행될 수 있다.
에이전트 안전성의 핵심은 “더 좋은 프롬프트”가 아니라 실행 경계다.
목차
- #제안과 실행은 다른 상태다
- #승인은 버튼 하나가 아니라 내구성 있는 상태다
- #승인된 쓰기는 원본이 아닌 샌드박스에서
- #승인은 실행 범위 안에서도 다시 나뉩다
- #자동화의 목표는 승인 제거가 아니다
- #결론
- #관련 노트
제안과 실행은 다른 상태다
에이전트가 도구 호출을 만들었다고 해서 그 작업이 실행된 것으로 처리하면 안 된다.
proposed -> waiting_approval -> executed
-> rejected
-> failed
proposed는 모델이 작업을 원한다는 의미일 뿐이다. 실제 시스템을 변경했다는 증거가 아니다. 승인된 요청의 구체적인 인자와 실행 결과를 영속적으로 남겨야 한다.
이 구분이 없으면 UI는 실행되지 않은 작업을 완료로 보여줄 수 있고, 에이전트는 실제로 받지 못한 도구 결과를 받았다고 오해할 수 있다.
승인은 버튼 하나가 아니라 내구성 있는 상태다
사용자 승인을 메모리에만 저장하면 프로세스가 종료되는 순간 대기 중이던 작업이 사라진다. 반대로 이미 실행된 작업을 다시 승인받아 중복 실행할 수도 있다.
승인 레코드에는 최소한 다음 정보가 필요하다.
id: approval-123
run_id: run-456
tool: repo.write
arguments:
path: src/auth.ts
status: pending
created_at: 2026-09-01T10:00:00Z
decided_at: null
result: null
재시작한 뒤에는 남아 있는 승인과 작업 상태를 조인해야 한다.
- 대기 중이면 같은 승인 UI를 복구한다.
- 이미 실행됐다면 결과를 복구한다.
- 거절됐다면 거절 결과를 에이전트에게 전달한다.
- 실행 여부를 알 수 없다고 자동 재실행하지 않는다.
승인된 쓰기는 원본이 아닌 샌드박스에서
사용자가 코드 수정을 승인했다고 해서 현재 작업 디렉터리를 바로 수정해야 하는 것은 아니다. 승인은 “이 범위의 작업을 시도해도 된다”는 의미이지 “원본을 즉시 덮어써도 된다”는 의미가 아니다.
실용적인 로컬 샌드박스는 다음과 같은 흐름을 가진다.
- 대상 저장소를 복사한다.
- 복사본 안에 독립적인 Git baseline을 만든다.
- 네트워크를 차단하고 쓰기 가능 범위를 샌드박스 안으로 제한한다.
- 코드 수정과 테스트를 실행한다.
- diff와 테스트 결과를 사용자에게 보여준다.
- 별도의 검토 후 원본 반영이나 PR 생성을 결정한다.
이 방식은 에이전트의 실수를 방지할 뿐 아니라 사용자가 결과를 검토하기 쉽게 만든다.
승인은 실행 범위 안에서도 다시 나뉩다
모든 쓰기 작업의 위험이 같지는 않다.
읽기 -> 자동 허용 가능
샌드박스 파일 쓰기 -> 작업 단위 승인
외부 네트워크 요청 -> 목적지와 payload 검토
Git push -> 브랜치와 remote 검토
PR 생성 -> 최종 사용자 승인
삭제·결제·메일 -> 매번 명시적 승인
플러그인은 자신이 필요로 하는 파일, shell, network, secret 권한을 manifest에 선언해야 한다. 에이전트에게 플러그인을 주는 것과 각 도구를 실행할 권한을 주는 것도 분리할 필요가 있다.
자동화의 목표는 승인 제거가 아니다
좋은 자동화는 사용자에게 모든 클릭을 요구하지 않는다. 그렇다고 모든 승인을 없애는 것도 아니다.
자동화해야 하는 것:
- 반복적인 읽기와 분석
- 샌드박스 생성
- 테스트와 diff 수집
- 위험도 계산
- 승인에 필요한 정보 정리
사용자가 남겨야 하는 결정:
- 외부 상태를 변경할지
- 시크릿을 제공할지
- 파괴적 작업을 수행할지
- 검토한 변경을 원본에 반영할지
결론
AI 에이전트의 안전성은 모델이 절대 실수하지 않을 것이라고 믿는 데서 나오지 않는다. 실수해도 복구할 수 있고, 실행 범위가 제한되며, 실제로 무엇을 했는지 검토할 수 있는 구조에서 나온다.
제안과 실행을 분리하고, 승인을 영속 상태로 만들고, 쓰기를 샌드박스에서 수행하며, diff와 결과를 다시 사용자에게 돌려주는 것. 이것이 실제로 작업하는 AI 에이전트의 최소 안전 경계라고 생각한다.
안전한 에이전트는 실수하지 않는 에이전트가 아니라, 실수의 범위가 제한되고 결과를 추적·검토·복구할 수 있는 에이전트다.
관련 노트
- AI 에이전트와 함께 개발하기 — 에이전트 협업 방식에 대한 메모
- claude code agent teams — 여러 에이전트의 역할 분리와 조율
- agent team — 에이전트 팀 구성 아이디어
- mcp 만들고 설치하기 — 에이전트 도구 연결을 직접 구성한 기록